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ABSTRACT 

The  properties  and  characteristics  of  a  recently  developed  set  of 
hardwired  Register  Transfer  Modules  (RTMs),  which  can  be  interconnected 
to  perform  the  functions  of  a  digital  computer,  are  presented.  To 
illustrate  the  value  of  this  higher  level  of  computer  design,  sets  of 
simulated  RTMs  were  combined  to  carry  out  the  operations  of  both  a 
general  purpose  digital  computer,  and  a  digital  computer  designed  to 
perform  specific  tasks. 

The  general  purpose  computer  capabilities  were  demonstrated  by 
interconnecting  modules  to  perform  the  various  functions  of  a  FORTRAN 
machine.  The  specific  task  application  was  shown  by  constructing  a 
system  of  modules  to  perform  a  triangulatiors  algorithm,  This  application 
also  demonstrates  how  the  concept  of  modularization  could  be  applied  to 
a  1969  proposal  by  the  Navy  for  a  single,  modularized  airborne  computer 
system  known  as  the  Advanced  Airborne  Digital  Computer  (AADC). 
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I.   INTRODUCTION 

In  the  design  of  digital  computers,  the  solution  to  most  problems 
is  carried  out  at  the  basic  hardware  level  -  that  is,  the  NAND  and  NOR 
gate  level  of  operations.  Problem  formulation  at  this  level,  however, 
is  very  difficult  due  to  the  significant  effort  required  to  manipulate 
the  large  number  of  logical  equations  associated  with  these  gates.  Sub- 
sequently, most  problem  formulation  and  conceptualization  is  accomplished 
at  the  level  of  register  transfer  operations.  It  is  at  this  level  that 
control  signals  are  set  up  to  cause  information  to  be  transferred  between 
registers. 

There  have  been  various  attempts  to  write  logical  design  simulators 
and  to  carry  out  the  detailed  sequential  and  combinational  logic  designs 
from  this  register  transfer  level.  Until  recently  however,  there  has 
been  little  or  no  attempt  to  design  a  common  set  of  hardware  modules  to 
be  taken  as  primitive  operations  based  on  register  transfers  in  the 
same  way  that  various  flip-flops  and  NAND  and  NOR  gates  have  been  uti- 
lized. Bell  and  Grason  have  undertaken  this  task  in  Reference  [1].  Their 

efforts  have  resulted  in  the  design  of  a  set  of  register  transfer  modules 
(called  RTMs)  which  are  used  as  a  basis  for  digital  systems  design  and 
have  the  property  of  allowing  a  digital  system  to  be  specified  without 
the  usual  switching  circuit  design.  These  modules  are  the  basis  for  the 
concepts  presented  in  this  paper. 

Reference  [2]  discusses  the  concept  of  an  Advanced  Avionics  Digital 
Computer  (AADC)  proposed  in  1969  as  a  single  computer  design  to  satisfy 
the  majority  of  Navy  airborne  computing  requirements  in  the  1975-1985 
time  period.  The  objective  forwarded  in  this  proposal  is  the  use  of  one 


set  of  standard,  efficiently  designed  hardware  modules  which  would  allow 
flexibility  in  configuring  a  computer  organization  for  specific  func- 
tional applications.  The  ultimate  objectives,  of  course,  are  increased 
reliability  and  improved  cost  effectiveness  by  the  use  of  "throw-away" 
module  repair  techniques. 

This  paper  presents  a  set  of  simulated  register  transfer  modules, 
written  in  ALGOL,  which  can  be  combined  to  perform  either  as  a  specific 
task  computer  or  in  a  general  purpose  configuration  thus  demonstrating 
the  feasibility  of  combining  hardware  modules  in  this  manner.  In 
addition,  a  simulation  program  which  combines  these  modules  to  solve 
a  simple  triangulation  problem  is  presented  as  evidence  of  their  possible 
use  in  solving  the  AADC  problem. 


II.  NATURE  OF  THE  PROBLEM 

A.   SELECTION  OF  REGISTER  TRANSFER  MODULES 

The  formulation  of  algorithms  which,  when  executed  by  hardware, 
solve  the  computer  logical  design  problem  is  a  concern  of  most  digital 
system  design  engineers,  figure  1  of  Reference  [1]  presents  a  comparison 
of  the  solutions  to  the  various  design  problems  using  programming,  con- 
ventional logic  design  and  Register  Transfer  Modules.  Each  of  these 
three  processes  have  the  same  goals  namely:  to  construct  a  program  for  a 
machine,  or  to  construct  a  hardwired  machine,  which  will  execute  an 
algorithm  to  solve  the  problem.  The  fundamental  results  of  the  compari- 
son is  that  RTMs  can  be  considered  as  a  set  of  basic  components  for  con- 
structing hardwired  algorithms  --  that  is,  they  are  the  basic  components 
for  the  design  of  digital  systems. 

There  is  a  wide  range  of  problem  areas  in  which  the  RTM  approach 
may  simplify  the  design  process.  For  example,  in  computer  related  work, 
one  might  use  the  modules  as  a  controller  for  a  simple  device  such  as  a 
card  reader,  requiring  only  a  few  control  states.  More  complex  tape  and 
disk  controllers  with  many  states  would  have  a  higher  design  payoff. 

The  RTM  approach  seems  particularly  appropriate  for  installations 
with  several  "old"  computers  to  which  special  devices,  such  as  communica- 
tions lines  are  attached.  It  is  intended  that  the  modules  discussed  here 
will  make  the  design  of  special  purpose  processers  practical  (Ref.  1). 
The  hardwiring  of  general  purpose  computers  is  also  an  interesting 
application  of  this  design  approach. 

The  preliminary  design  problems  of  this  model  were:  defining  a  set 
of  modules  to  carry  out  the  desired  algorithms;  formulating  the 


interconnecting  structure  of  the  modules  so  that  various  classes  of 
algorithms  could  be  solved;  and,  selecting  a  simulation  language  to  check 
the  design. 

In  defining  a  set  of  modules,  consideration  was  given  to  the  design 
constraints  listed  in  Reference  [1].  They  are: 

1.  Hardware  Technology  Constraints.  This  set  of  constraints 
dictates  the  hardware  from  which  the  modules  are  constructed. 

2.  Problem  Constraints.  Each  digital  system  problem  can  be 
characterized  by  its  hardware  (and/or  programming)  requirements.  For 
example,  these  constraints  include  word  length,  number  base,  operation 
types,  etc.  This  set  of  constraints  is  roughly  a  measure  of  the  problem 
size. 

3.  User  Constraints.  These  constraints  are  both  objective  and 
subjective  because  they  reflect  how  a  human  user  views  the  modules  (e.g.. 
cost,  ruggedness,  reliability,  ability  to  debug)  for  solving  a  particular 
class  of  problems. 

4.  Internal  Constraints.  Constraints  coming  from  the  organization 
and  individuals  building  the  modules  (e.g.,  corporate  profit  and 
fabrication  technology). 

The  constraints  on  hardware  technology  are  mostly  fixed  and  usually 
dictated  by  integrated  circuit  technology.  The  only  hardware  related 
constraint  affecting  this  project  however,  was  word  length.  Since  most 
computers  use  8,  12  or  16  bits,  a  word  length  of  16  bits  was  chosen  to 
minimize  any  conflict  in  this  area.  Additional  hardware  constraints 
which  do  not  come  into  play  in  this  project  are  discussed  in  detail  in 
Reference  [1]. 

The  constraints  which  were  most  significant  in  development  of  this 
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model  were  of  the  second  type,  i.e.,  protlem  dictated.  Computer  problems 


are  usually  measured  by  the  number  of  statements  (control  operations) 
they  contain,  the  number  of  register  operations  they  perform,  or  the 
amount  of  memory  they  require.  The  RTMs  simulated  in  this  project  were 
designed  for  up  to  100  hardwired  control  steps,  multiple  arithmetic 
units,  and  a  small  read-write  memory  of  about  100  words.  The  simulated 
modules  were  thus  appropriately  constrained. 

Although  cost,  circuit  structure,  and  other  user  dictated  and 
internal  constraints  bear  heavily  on  the  design  of  actual  hardwired  RTMs, 
they  are  not  considered  significant  to  the  construction  of  this  model. 
It  is  significant  to  note  that  similar  modules  are  being  built  and 
additional  discussion  of  the  constraint  areas  concerning  the  actual  RTMs 
is  available  in  Reference  [1]. 

The  characteristics  of  the  individual  Register  Transfer  Modules 
used  in  this  model  ere   discussed  in  Section  III. 

B.   AN  RTM  COMPUTER  DESIGN 

A  valuable  and  remunerative  use  for  the  RTM  system  is  in  the 
simplicity  of  designing  either  special  purpose  or  general  purpose 
computers.  An  example  is  a  small  stored  program  computer  which  was 
designed  by  Bell  and  Grason  using  RTM  modules,  and  was  roughly  equivalent 
to  the  Digital  Equipment  System's  PDP-8  (Ref.  1).  The  process  of  specify- 
ing this  machine  using  both  ISP  (Instruction  Set  Processor)  and  RT 
(Register  Transfer)  descriptions  took  approximately  six  manhours.  The 
computer  was  wired,  and  aside  from  minor  connection  problems  in  the  RTMs, 
the  computer  operated  essentially  when  power  was  applied  since  there 
were  no  logic  errors.  The  computer  was  designed  for  an  actual  applica- 
tion which  had  about  300  constants,  600  control  steps  a;~d  about  16 
variables.  An  alternative  approach  would  have  been  to  .hardwire  the  600 
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control  steps  directly,  but  this  would  make  the  model  more  costly  and 
less  flexible.  The  computer  had  only  24  simple  and  16  decision  modules. 
Since  the  price  ratio  of  a  hardwired  control  to  a  stored  control  is 
approximately  10:1,  it  was  cheaper  to  use  RTMs  to  build  the  computer  and 
then  let  the  computer  program  execute  the  control  steps.  According  to 
Reference  [1],  the  overall  cost  of  an  actual  RTM  implementation  appears 
to  be  at  least  a  factor  of  4  cheaper  than  some  of  the  alternative 
register  transfer  approaches  to  computer  design. 

C.   AADC  CONCEPT 

The  procedure  within  the  Navy  has  been  to  specify  computational 
requirements  for  a  new  system  design  and  then,  generally,  to  procure 
either  a  special  purpose  computer  or  a  near  optimum  general -purpose 
machine  which  will  satisfy  the  requirements.  This  procedure  generates 
a  situation  where  a  relatively  large  and  diversified  group  of  machine 
hardware  and  software  packages,  and  associated  repair  components  must 
be  maintained  in  inventory.  Not  only  are  these  machines  generally  not 
adaptable  or  expandable  for  use  in  different  functional  areas,  but  the 
development  cycle  for  a  new  machine  tends  to  become  lengthy  and  costly. 
This  procedure  provides  the  motivation  for  the  development  of  a  single, 
highly  flexible,  and  functionally  adaptable  computer  design  -  the 
Advanced  Avionics  Digital  Computer. 

The  possible  use  of  Register  Transfer  Modules  to  fill  the  design 
requirements  of  the  proposed  avionics  system  was  actually  the  inspira- 
tional motivation  for  this  thesis.  It  was  desired  to  demonstrate  the 
use  of  these  modules  in  this  application. 


III.  THE  MODEL 

The  RTM  system  modeled  in  this  project  consists  of  eight  types  of 
Register  Transfer  Modules  and  a  method  of  interconnecting  modules  via  a 
common  bus  which  carries  data  and  timing  interlock  signals  between  the 
modules.  Some  of  the  modules  connect  to  a  bus  in  order  to  transfer  data, 
and  the  remaining  modules  "control"  when  data  is  to  be  transferred.  The 
interconnecting  structure  of  the  modules  used  in  this  project  are  taken 
from  Bell  and  Grason's  model.  This  structure  is  flexible  and  efficient, 
and  since  the  type  of  structure  used  is  not  critical  to  this  project, 
the  use  of  an  already  proven  structure  was  desirable. 

The  Instruction  Set  Processor  language  as  used  here  is  a  language 
for  describing  the  register  transfer  operations  of  the  RTM's.  The  only 
parts  of  this  language  used  in  describing  the  modules  are  those  commonly 
known  to  the  digital  systems  engineer.  The  module  types  modeled  in  this 
project  are: 

1.  DM  for  memory.  The  DM  (data  memory)  part  is  just  the  registers 
which  hold  data  between  statements;  these  essentially  correspond  to  the 
variable  declarations  of  a  program.  The  operations  on  memory  are 
usually  just  reading  («-M)  and  writing  (M<-). 

2.  K  for  control.  The  K  modules  are  responsible  for  the  movement 
of  data  between  modules  by  appropriately  evoking  operations  on  the  DM 
(memory)  types.  The  K  modules  are  similar  to  the  control  structure  of  a 
program.  They  control  the  times  at  which  various  statements  are  evoked, 
and  are  also  used  to  make  decisions  about  which  controls  are  to  be 
evoked  next.  These  modules  are  used  to  connect  a  sequence  of  operations 
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together  as  in  a  subroutine  and  to  synchronize  control  when  there  is  more 
than  one  operation  taking  place  at  a  time. 

RTMs  provide  for  two  basic  data  types:  booleans  (  a  single  bit); 
and  16-bit  two's  complement  integers.  The  16  bits  of  a  register,  R, 
are  denoted  R<15:0>  where  the  bit  R<j>  has  the  value  2  . 

The  bus  carries  the  data  between  the  registers  for  the  various 
transfer  commands.  All  memory  modules  connect  to  the  bus  for  inter- 
register  transfers.  There  are  register  interlock  signals  associated 
with  data  transmission  to  insure  that  the  data  on  the  bus  is  valid.  The 
bus  has  storage  for:  the  16  data  bits;  an  arithmetic  overflow  bit;  and 
other  signals  to  control  the  data  transfer  --  including  the  control 
signal  to  indicate  that  the  function  evoked  has  been  completed.  K 
modules  connect  to  the  bus  and  use  the  evoke  function  completed  signal . 

In  selecting  a  language  in  which  to  model  the  desired  concepts 9 
consideration  was  given  to  the  particular  languages  available  on  the  IBM 
360/67  installation  at  the  Naval  Postgraduate  School,  the  availability 
and  ease  of  bit  operations  within  these  languages,  and  the  speed  of 
compilation  of  the  languages  on  this  system.  FORTRAN,  ALGOL  W  and  PL/1 
were  the  major  algebraic  languages  available.  ALGOL  W  was  selected 
because  the  version  of  FORTRAN  in  use  does  not  have  bit  operations  and 
PL/1  is  slower  in  compiling. 

A.   BASIC  MODULES 

There  are  four  basic  modules  which  are  necessary  to  the  construction 
of  non-trivial  digital  systems:  Ksimple,  DMgpa,  Kdecision  and  Kbus. 
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An  operational  description  of  each  of  these  modules  is  given  in  the 
following  paragraphs.  Diagrams  and  additional  information  for  these 
modules  are  available  in  Appendix  A. 

Ksimple  (Ks)  is  the  basic  module  which  evokes  a  function  consisting 
of  a  data  operation  and  a  register  transfer.  When  a  Ksimple  is  evoked, 
it  in  turn  evokes  the  operation  function  and  then  evokes  the  next  K 
module.  The  data  operation  is  basically  the  righthand  side  of  an 
assignment  statement,  or  the  part  read  from  a  memory  location,  e.g., 
«-X  and  -f-Y+Z.  The  register  transfer  part  is  the  lefthand  side  of  an 
assignment  statement,  e.g.,  CK  or  MA-*-.  The  diagram  for  Ks  with  its  two 
inputs  and  two  outputs  is: 


1 


evoke  this  control /ev 


Ks  (Name  of  function 
to  be  evoked) 


cvuKc     a     luiiltiuii/cvni 


T 


evoked  function  complete/evfnc 


evoke  the  next  control  function/evn 


The  ALGOL  simulation  of  the  Ksimple  module  is  shown  in  Appendix  B. 

The  DM  (general  purpose  arithmetic)/gpa  allows  arithmetic  function 
results  (data  operations)  which  have  been  performed  on  its  two  registers 
Rl  and  R2,  to  be  written  into  other  registers  and  locations  (using  the 
bus).  A  complete  diagram  is  shown  in  Appendix  A.  Numbers  are  repres- 
ented in  two's  complement  form.  Results  can  also  be  transferred  into 
Rl  and  R2  (Rl-*-,  R2-0 .  The  complete  list  of  data  operations  is  shown  in 
Appendix  B.  All  bits  of  both  registers  Rl<15:0>  and  R2  1 5 :0>  are  avail- 
able as  booleans  to  be  tested.  Data  can  be  shifted  into  the  left  and 
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righthand  bits  on  /2  and  *2  operations,  respectively,  in  which  case 
an  overflow  flag  is  activated. 

The  ALGOL  W  simulation  model  for  this  project  contains  two  general 
purpose  arithmetic  modules,  GPA  and  GPA2.  GPA  is  the  main  gpa  and  is 
designed  to  fulfill  all  the  requirements  of  the  gpa  described  in  Bell 
and  Grason's  model.  GPA2  is  a  more  restricted  version  of  the  main  gpa 
which  is  designed  to  handle  small  administrative  tasks  in  the  program. 
It  has  fewer  data  operations  and  operates  synchronously  with  the  main 
gpa  using  the  same  data  bus. 

Appendix  B  contains  a  listing  of  the  numbers  assigned  the  various 
data  operations  which  are  performed  in  the  GPA,  and  a  listing  of  the  GPA 
module. 

The  Kdecision  (Kd)  module  provides  for  the  routing  of  control  flow 
based  on  the  condition  of  a  boolean  input.  The  diagram  for  Kd  with  its 
two  inputs  and  two  outputs  is: 


boolean  input 


evoke  this  control /ev 


Kd  (boolean  input  condition  being  tested) 


evn  l/(evoke 
next  if  boolean 
is  true 


evn  0/ (evoke  next 
if  boolean 
is  false 


V 


Each  time  a  decision  control  is  evoked,  it  in  turn  evokes  one  of  the 
controls  attached  to  it  depending  on  whether  the  boolean  input  is  true 
(a  1)  or  false  (a  0). 

The  Kbus  module  requires  a  centralized  control  module  for  each  inde- 
pendent data  bus  in  the  system.  It  has  a  register,  Bus,  which  always 
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contains  the  result  of  the  last  register  transfer  that  took  place  via 
the  bus.  Each  bit  of  the  bus  is  available  as  a  boolean.  As  denoted  in 
Reference  [1],  the  bus  module  carries  out  the  following  functions: 

1.  monitors  all  register  transfer  operations  and  supplies  the 
evoke  function  completion  control  signal,  evfnc,  to  indicate  the 
requested  function  has  been  completed; 

2.  provides  for  single  step  control  by  the  user,  thus,  a  push 
button  can  be  used  to  step  each  register  transfer  operation  and  create 
the  evoke  function  completed  signal; 

3.  provides  for  sense  lights  to  be  connected  to  the  bus  register 
so  that  data  transfers  which  use  the  bus  may  be  monitored. 

4.  provides  for  a  word  source  of  zero,  i.e.,  -*-0; 

5.  multiple  register  transfers  can  be  made  in  one  statement  A«-B*-OD 
(to  reset  A,  B,  and  C) ; 

6.  provides  for  a  null  operation  which  allows  data  to  be  trans- 
ferred to  the  Bus  register  for  testing,  i.e.,  Bus*-; 

7.  forms  the  following  boolean  functions  which  are  available  after 

each  control  step  using  the  bus: 

Bus  <15:0>  =  0  (detects  whether  the  last  word 

transferred  was  a  zero) 

Bus  <15>,Bus<14>,. . . ,     (16  booleans,  1  for  each  bit) 

Bus  <0> 

Overflow  (the  register  arithmetic  operation 

caused  an  overflow,  e.g.,  -«-A+B, 

«-Ax2) 

8.  resets  all  modules  when  power  is  applied; 

9.  provides  a  manual  start  signal  to  evoke  the  first  control; 
10.  provides  electrical  termination. 

Obviously,  it  is  not  necessary  to  simulate  within  the  simulated 
bus  model  all  of  the  above  functions  as  some  of  them  are  merely  direct 
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connections.  Functions  1,2,4,5,  6,  and  7  were  therefore  the  primary 
objective  of  the  simulation  program. 

The  four  aforementioned  modules  are  essential  for  a  small 
non-trivial  computer  system.   Some  of  the  additional  modules  which  are 
available  and  add  variety  and  sophistication  to  the  RTM  model  are: 

K(branch)  -  allows  control  to  be  passed  to  a  number  of  controls 

in  parallel  (simultaneously) 
K(serial  merge)  -  allows  several  control  sequences  to  terminate 

in  series  and  form  a  single  control  evoke. 
K(parallel  merge)  -  allows  several  control  sequences  to  terminate 

in  parallel  and  form  a  single  control  evoke. 
K(manual  evoke/me)  -  provides  an  interface  between  the  RTM  system 

and  the  human  user. 
K(clock)  -  generates  a  control  signal  at  periodic  intervals. 
K(delay)  -  delays  the  next  evoke  signal  for  a  period  of  time. 
There  are  some  20  types  of  -Register  Transfer  Modules  presently 
available  and  described  in  Reference  [1],  and  it  is  considered  that  this 
number  will  increase  as  technology  advances  and  various  tasks  evolve. 
A  complete  listing  of  all  modules  available  is  given  in  Appendix  A. 

The  following  is  a  list  of  the  modules  that  were  written,  tested 
and  combined  in  this  project  to  simulate  the  various  digital  computer 
capabilities.  The  four  basic  modules  have  already  been  discussed.  The 
remaining  modules  are  described  in  subsequent  sections. 
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BASIC 

ARITHMETIC 

FLOATING  POINT 

TRIGONOMETRIC 

KSIMPLE 

ADDER 

FADD 

SINANG 

KBUS 

KTIMES 

FSUB 

ARCSIN 

KTEST 

KDIVIDE 

FDIVIDE 

ANGTAN 

GPA 

Kbranch 
Kboolean 

FTIMES 

B.   ARITHMETIC  MODULES 

In  any  computer,  certain  basic  arithmetic  operations  are  required 
which  are  more  complex  than  those  simple  data  operations  performed  in 
the  gpa  module.  Some  of  these  operations  are  add,  subtract,  multiply, 
divide,  etc.  In  order  to  demonstrate  the  capability  of  the  RTM  system, 
these  arithmetic  operation  modules  were  constructed  using  basic  system 
hardware  and  other  RTM  system  modules  already  developed. 

Appendix  C  presents  a  diagram  of  a  16  bit  adder/subtractor  which 
performs  either  addition  or  subtraction  depending  on  a  flag  in  the  call- 
ing module,  using  the  logical  AND/OR  operations  on  each  of  the  bits. 
The  operation  of  the  adder  is  similar  to  that  described  for  a  full 
adder  in  Reference  [3]. This  adder  would  normally  be  contained  in  the  GPA 
but  in  the  simulation  model  it  was  constructed  separately  and  called  from 
the  GPA. 

A  16  bit  integer  multiplier  is  shown  in  Appendix  D.   The  diagram 
includes  two  parts:  the  K  modules  for  control,  showing  the  control  flow, 
and  the  DM  modules  to  hold  the  result.  Given  the  physical  location  of 
the  modules,  the  diagram  would  represent  a  complete  wiring  diagram. 

The  user  may  think  of  the  structure  as  being  analagous  to  entering 
a  program  subroutine  and  that  is  exactly  how  it  was  modeled  in  ALGOL  - 
as  a  subroutine  carrying  out  a  conventional  method  of  i  jltiplication. 
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The  operation  is  best  explained  by  using  the  flow  chart  of  the  RTM 
description  (Appendix  D).  In  carrying  out  this  algorithm,  the  multiplier 
is  first  placed  in  the  right  16  bits  of  a  32  bit  register,  P<31:0>, 
composed  of  a  16  bit  accumulator  attached  to  a  16  bit  multiplier  register. 
The  left  16  bits  of  this  register  are  initially  set  to  zero.  The  right- 
most bit  of  the  register,  P<0>,  is  then  examined  and  if  a  "1"  is  con- 
tained therein,  the  16  bit  multiplicand  is  added  to  the  left  16  bits  of 
the  register.  The  entire  register  is  then  shifted  right  one  bit,  and  the 
righthand  bit  again  examined.  This  process  is  carried  out  sixteen  times 
and  upon  completion  the  32  bit  product  is  contained  in  the  register. 
This  product  must  then  be  scaled  to  the  most  significant  16  bits  for 
further  calculations.  Additional  information  on  this  algorithm  is 
available  in  Reference  [3]. 

A  16  bit  integer  divider  which  divides  to  the  nearest  integer  was 
also  constructed  for  use  in  the  program.  The  algorithm  in  this  module 
(subroutine)  was  taken  directly  from  that  shown  on  page  201  of 
Reference  [3].  The  construction  and  operation  of  this  module  is  very 
similar  to  that  of  the  multiplier. 

Normal  ALGOL  W  construction  was  used  to  simulate  the  hardwired 
versions  of  branching  (Kbranch)  and  boolean  (kboolean)  operations.  Other 
basic  arithmetic  operation  modules  such  as  square  root,  exponentiation, 
etc.,  can  be  easily  constructed  given  the  proper  algorithm  and  the 
necessary  Register  Transfer  Modules. 

C.   FLOATING  POINT  MODULES 

Floating  point  arithmetic  is  a  definite  asset  in  solving  certain 

classes  of  computer  problems  having  a  wide  range  of  numerical  values.  It 

was  therefore  considered  appropriate  to  demonstrate  that  floating  point 

arithmetic  '/as  possible  using  Register  Transfer  Modules. 
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The  word  length  chosen  for  the  floating  point  model  was  maintained 
at  16  bits  for  uniformity  and  was  broken  up  as  follows: 

Bit  <15>       the  sign  of  the  number.  A"0"  represented  a 

positive  number,  "1"  a  negative. 
Bits  <14:10>    the  exponent  of  the  number.  Both  negative  and 

positive  exponents  were  possible  using  the 

following  convention: 

00000  -  01111  negative  exponents, 

10000  zero 

10001  -  mil  positive  exponents. 

Bits  <9:0>      the  two's  complement  representation  cf  the 

mantissa. 
Floating  point  arithmetic  is  similar  to  integer  arithmetic  except 
that  it  must  meet  the  following  restrictions  on  operations  with  exponents 
(A  x  2r)  x  (B  x  2s)  =  (A  x  B)  x  2r+s 
(A  x  2r)  t  (B  x  2s)  =  (A  t  B)  x  2r"s 
(A  x  2r)  +  (B  x  2r)  =  (A  +  B)  x  2r 
(A  x  2r)  -  (B  x  2r)  =  (A  -  B)  x  2r 
In  the  latter  two  operations,  it  will  usually  be  necessary  to  scale  one 
of  the  numbers  so  that  it's  exponent  equals  the  exponent  of  the  other 
number. 

The  floating  point  arithmetic  modules  were  constructed  using  an 
appropriate  combination  of  the  previously  discussed  Register  Transfer 
Modules.  They  simply  consist  of  a  set  of  modules  for  carrying  out  the 
proper  exponent  operations,  a  call  to  the  appropriate  integer  arithmetic 
module  to  conduct  the  operation,  and  a  scaling  routine  to  reduce  the 
result  to  the  ten  most  significant  bits  and  update  the  xponent,  if 
necessary. 

18 


Appendix  E  contains  a  flowchart  of  the  floating  point  "add"  sub- 
routine. Similar  floating  point  modules  for  the  operations  of  subtrac- 
tion, multiplication  and  division  were  constructed  and  tested 
satisfactorily  in  the  model. 

D.  TRIGONOMETRIC  MODULES 

Trigonometric  operations,  like  the  floating  point  operations,  have  a 
wide  range  of  uses  in  today's  modern  digital  computer.  They  are  particu- 
larly useful  in  a  majority  of  the  airborne  computer  problems.  Since  one 
of  the  objectives  of  this  paper  is  to  show  that  there  are  possible  uses 
for  Register  Transfer  Modules  in  airborne  computer  systems,  it  was  con- 
sidered appropriate  to  demonstrate  how  the  modules  can  be  used  to  com- 
pute trigonometric  functions.  The  functions  of  sine,  arcsine  and 
arctangent  were  chosen  for  this  demonstration  since  these  are  the  opera- 
tions used  in  the  triangulation  problem  discussed  later  in  this  paper. 

The  algorithm  for  each  of  these  modules  consists  of  a  set  of  basic 
integer  modules  combined  to  approximate  the  infinite  series  equations 
for  the  operation  in  question,  with  some  constant  modules  intermixed  for 
scaling  operations.  These  scaled  integer  operations  are  used  instead  of 
using  the  floating  point  modules  because  of  their  simplicity.  The  scale 
used  in  these  modules  is  dependent  on  the  accuracy  required  for  the 
particular  application  and  can  be  modified  accordingly.  For  the  applica- 
tion presented  in  this  paper,  the  calling  fractional  parameters  were 

3  3 

multiplied  by  10  ,  and  the  returned  result  was  divided  by  10  ,  thus, 

allowing  all  calculations  to  be  accomplished  in  integer  arithmetic,  while 

maintaining  a  minimum  accuracy  of  two  significant  digits  to  the  right  of 

the  decimal  point  in  any  real  number  value. 

A  RT  diagram  of  the  ALGOL  simulated  module  for  the  ARCSIN  is  given 

in  Appendix  F. 
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IV.  EXPERIMENTAL  RESULTS 

A.  GENERAL  COMPUTING 

Figure  1  shows  a  diagram  of  a  simple  RTM  program  which  computes  the 
sum  of  the  integers  0  to  N.    Figure  2  is  the  listing  of  the  ALGOL 
program  which  simulates  this  simple  algorithm.  Several  simple  algorithms 
of  this  type  were  used  to  verify  that  the  simulated  modules  worked  pro- 
perly and  were  consistent  with  the  principles  and  concepts  of  RTM 
operation  in  Reference  [1]. 


CONTROL  PART 


DATA  PART 


i 


BEGIN 


^L 


Ks(S  «-  S+N) 


evn 
ev 


Ks(N  ■«-  N-l) 


evn 


ev 


Ks(Bus  =  0) 


evnO 


i 


evfn 


By^  =  0 


evoke  function  complete 


No    Yesrevnl 
erid 


Figure  1.  Sum  of  Integers  to  N 
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LISTING  MEANING 

KSIMPLE(O);  Set  Rl   to  0 

KSIMPLE(18);  Set  R2  to  0 

L:  =  10;  Select  memory  location 


KSIMPLE(17) 

0VER:KSIMPLE(26) 

KSIMPLE   (6) 


Rl  +  mem(10) 
R2  *■  Rl  +  R2 
Rl  -e-  Rl   -  1 


KTEST  (M);  TEST  BUS  s  0 

IF  M  =  0  THEN  GO  TO  OVER;  If  false  repeat  loop,  otherwise 

drop  out  of  loop. 

Figure  2.     Sum  of  Integers  to  N  ALGOL  Listing. 

B.  SPECIFIC  TASKS 

To  demonstrate  the  use  of  the  RTM  system  in  specific  task  computing, 
the  available  RTMs  were  used  to  simulate  a  number  of  FORTRAN  functions. 

Simple  operations  such  as  assignment,  statements,  branching,  etc.,  were 

successfully  demonstrated  with  little  difficulty,  since  they  only 

required  simulation  of  a  direct  hardwired  connection.  A  more  complex 

operation  of  a  FORTRAN  machine  which  was  simulated  however,  was  the 

FORTRAN  DO-LOOP.  The  system  of  RTM  modules  required  to  carry  out  this 

operation  is  given  in  Figure  3,  with  an  explanation  of  the  meaning 

attached  to  each  of  the  steps  in  the  algorithm.  The  successful  completion 
of  this  algorithm  was  an  indication  that  other  operations  of  a  FORTRAN 

machine,  including  subroutine  calls,  were  within  the  capability  of  the 
RTM  system. 

Other  examples  of  the  use  of  Register  Transfer  Modules  in  specific 
task  computing  were  demonstrated  in  the  construction  of  the  floating  point 
modules  and  in  the  triangulation  algorithm. 

C.  TRIANGULATION 

The  functional  modularity  of  the  RTM  system  allows  a  tremendous 
flexibility  in  the  type  of  computer  system  that  can  be  designed  and  it 
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was  felt  that  this  modularity  could  be  useful  in  solving  the  problems 
presented  in  the  AADC  concept. 

LISTING  MEANING 

CLEAR;  set  all  registers  to  0 

L:=l;  select  memory  location 

KSIMPLE(34)  R2«-mem(l);  initial  loop  value 

0VER:L:=0;  select  memory  location 

KSIMPLE(17); Rl+mem(0);  loop  increment 

+ 
statements 
to  be  executed 
in  the  loop 

KSIMPLE(26);  R2+-R1  +  R2 

L:=19;  select  memory  location 

KSIMPLE(17);  Rl  *■  mem(19);  loop  end  value 

KSIMPLE  (7);  Rl  <-  Rl  +  1  ; 

KSIMPLE  (10);  Rl  +   Rl  -  R2 

KIEST(M);  TEST  BUS  <  0 

IF  M=0  then  GO  to  OVER;  If  false  repeat  loop,  otherwise 

drop  out  of  loop. 

Figure  3.  FORTRAN  DO- LOOP  RTM  System. 

In  order  to  further  demonstrate  the  applicability  of  these  modules 
to  this  specific  task  it  was  considered  appropriate  to  model  one  of  the 
more  common  airborne  computer  problems.  The  problem  of  "Tri angulation" 
was  selected  for  this  example.  Triangulation  can  be  defined  in  this 
instance  as  the  computation  of  the  lead  angle  of  intercept  for  a  defen- 
sive weapons  system  (airborne  or  surface)  on  an  approaching  target. 

In  the  problem  situation,  the  defensive  weapon  platform  is  considered 
to  be  in  the  center  of  a  polar  coordinate  circle  which  is  oriented  to 
true  north.  All  positions  of  the  target  are  then  measured  relative  to 
the  center  of  the  circle.  Initiating  the  problem  are  any  two  successive 
inputs  of  a  mark  (range  and  bearing  of  the  traget  from  the  weapon  plat- 
form, and  time  of  the  mark).  Using  these  inputs,  the  proper  trigonometric 
identities,  and  the  Law  of  Sines,  the  program  computes  he  true  bearing  on 
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which  to  direct  the  defensive  weapon  in  order  to  intercept  the  target. 
The  flowcharted  algorithm  is  given  in  Appendix  G. 

The  algorithm  was  first  coded  in  conventional  ALGOL  W  using  three 
different  methods  -  the  Law  of  Sines,  the  Law  of  Cosines  and  Successive 
Iteration.  Successive  Iteration  is  the  computation  of  the  firing  bear- 
ing using  the  successive  computation  of  the  rate  at  which  the  target 
range  and  bearing  are  changing.  The  most  efficient  and  accurate  method 
was  found  to  be  the  one  using  the  Law  of  Sines,  and  thus  it  was  adopted 
for  the  RTM  system  model . 

The  triangulation  model  was  coded  and  tested  through  all  quadrants 
of  the  circle  using  the  ALGOL  modules  of  the  simulated  RTM  system.  In 
all  cases,  the  solution  computed  by  the  model  was  fast  and  accurate. 
The  solutions  were  generated  by  the  model  at  an  average  rate  of  3.93 
seconds  of  CPU  time  (IBM  360/67)  per  solution,  It  is  estimated  that  the 
simulation  model  would,  at  best,  be  only  one  half  as  fast  as  the  actual 
hardwired  version  of  the  system.  It  was  not  within  the  facility  of  the 
particular  version  of  ALGOL  W  to  measure  the  CPU  time  for  each  module. 
The  average,  CPU  time  however,  for  each  executable  statement  in  the 
algorithm  was  28  milli-seconds.  Since  each  RTM  module  requires  a  sub- 
routine call  and  contains  some  executable  statements,  the  execution  time 
for  each  RTM  is  probably  at  least  28  milli-seconds.  Hardware  versions 
that  operate  within  these  limits  can  easily  be  built,  and  thus  the 
simulation  model  is  considered  a  valid  indicator  of  the  minimum  speed 
of  solution. 

The  solutions  computed  by  the  simulated  RTM  system  were  verified 
first  by  the  "maneuvering  board"  method  as  described  in  Reference  [4], 
and  then  by  comparison  with  the  solutions  computed  by  he  conventional 
ALGOL  W  programs. 
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All  experimental  results  obtained  in  the  configurations  tested  were 
considered  representative  of  the  expected  performance  of  the  actual  RTM 
system,  and  appeared  to  be  consistent  with  the  concepts  and  principles 
of  the  actual  system  as  described  in  Reference  [1]. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  concept  of  using  high  level  building  blocks  is  not  new.  Various 
simulators,  register  transfer  devices  and  other  high  level  design  aids 
are  presently  being  developed. 

The  implementation  of  this  particular  set  of  simple  modules,  though 
not  unique,  appears  to  be  adequate  and  useful  in  many  different  areas. 
The  modules  can  be  applied  easily  and  effectively  to  most  problems  with 
consistent  results.  The  user  need  only  be  familiar  with  the  concept  of 
registers  and  register  operations  on  data,  and  have  a  fundamental 
understanding  of  a  flow  chart  in  order  to  use  RTM  concepts. 

According  to  Reference  [1],  the  hardwired  modules  described  herein 
are  fast,  simple,  efficient  and  accurate,  and  enjoy  a  significant  cost 
advantage  over  alternate  approaches  to  computer  design.  The  results 
obtained  with  the  simulated  modules  support  all  of  these  claims,  except 
the  last,  which  is  obviously  beyond  the  scope  of  simulation.  The 
simulation  of  the  simple  FORTRAN  machine  and  the  other  general  purpose 
algorithms  constructed  in  this  project  demonstrated  that  RTMs  could  be 
used  in  the  implementation  of  other  digital  computer  systems.  The  use 
of  Register  Transfer  Modules  in  this  capacity  is  therefore  considered 
quite  feasible,  and  allows  significant  flexibility  in  the  design  of 
these  systems.  All  of  these  highly  desirable  characteristics  should  be 
considered  in  the  design  of  any  new  digital  computer  system. 

The  most  significant  finding  of  this  project,  however,  was  the 
feasibility  and  usefulness  of  these  modules  in  specific  task  computing; 
in  particular  the  RTM  application  to  the  Advanced  Avio  cs  Digital 
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Computer  proposal  was  impressive.  The  successful  development  of  specific 
routines  for  trigonometric  functions  using  RTMs  was  instrumental  in  the 
continuation  of  research  in  this  area.  The  triangulation  problem  modeled 
was  highly  successful  in  all  respects.  The  RTM  modules  were  effectively 
combined  to  carry  out  the  complex  algorithm,  and  in  addition,  the  speed 
and  efficiency  achieved  exceeded  all  expectations.  Through  this  success- 
ful application  of  the  RTM  concept,  a  possible  solution  to  the  avionics 
computer  problem  has  been  found. 

A  sufficiently  high  speed,  low  cost,  modularized  computer  that  can  be 
configured  to  perform  any  task  effectively  and  efficiently  is  available 
with  the  use  of  Register  Transfer  Modules.  The  discovery  of  additional 
applications  for  these  modules  is  inevitable  and  it  is  highly  recommended 
that  additional  research  be  performed  in  this  area.  A  major  step  in  this 
research  might  be  to  obtain  actual  modules  for  experimentation  and 
construction  of  prototypes  for  an  AADC. 
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APPENDIX  A 


RTM  MODULES 


K  TYPE  MODULES 


K(simple/s)  =   Kfsubroutine  call/sc' 
Xevoke/ev 

evoke  function/evfn 


Ks  (function  evoked 
or  subroutine 
called) 


T 


evoke   function  cnmplete/evfnc 


evoke  next/evn 


K(decision/d) 


yevoke/ev 


Kd(boolean 
condition) 


boolean 
input 


T 


evnl /true/yes        YevnO/ false/no 


I 


K(bus  sense/bus) 


b  enable  overflow  set 


-0 


Bus«- 


Human 


)    stop  switch 


I    Advance  Kev 


■*- 


Kbus 


Bus<15:0> 


b  Overflow/ov 


b  Bus  <15:0> 


b  Bus  =  0 


->- 


evoke  function  complete/ 
ovfnc ■>- 


initializes  ev 
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M  TYPE  MODULES 


M(array;  core,  read  only,  ic  read-write) 


MA<- 

Marray 

Data  avail ; 
Busy; 

MA<15:0>    ; 
MB<15:0> 

b  Busy 

MA«-;  readw/ri 

tew 

b  Data  avail ; 

MA«-;  read- 
pause-write 

MB«- 

^MB 

M(boolean/b) 


B  +  0 

DMb 

_B_ 

optional 
optional 

b 

B 

B  <-  1 

b 

— ►- 
— ►- 

b 

-B 

B  «--»B 

B  <-  I 
I 

B  +  B©J 

J 

b 

<-  B 

B  <- 

X 
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M(general   purpose  arithmetic/gpa) 


=f 

^A 

di 

Co 

A 
B 

ngpa 

<15:0>; 
<15:0> 

b  A  <15:0> 

<-B 

b  B  <15:0> 

t— .A 

b  Carry  out/Co    w 

-H-.B 

(as  separated 

-*-A  +  B 

from  overflow) 

<-f\  -  B 

-*-A  -  1 

«-A  a   B 

4-AvB 

-*-A©  B 

<-A  +  1 

b 

<-A  x  2 

b 

<-(result)/2 

btt 

shift  in 

<16,- 

-1>  b 

A«- 

~_ 

B+ 

»-™ 

Other  Available  Modules 

K  type   (control ) 

K(branch) 

K( serial  merge) 

K(parallel  merge) 

K(manual  evoke) 

K(clock) 

K(delay) 


M  type  (memory) 

M(array;core,  read  only,  ic 
read-write) 


DM  type  (data  memory) 

DM(constants/K) 

DM(transfer  register/tr) 

T  type  (transducer) 

T(switch  register/sw) 

T(teletype) 

T(anal og-to-digi tal /a-d) 

T (digital -to-anal og/d-a) 
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APPENDIX  B 
KSIMPLE  AND  GPA  MODULE  SIMULATION 


Listing  of  Ksimple 

PROCEDURE  KSIMPLE(INTEGER  VALUE  J); 
BEGIN  INTEGER  I; 
I:  =  1; 
IF  J  >  17  THEN  BEGIN 

I:  =  2; 
J:  =  J-17; 
END 
DA:  =  1; 
DR:  =  0; 
GPA(J); 

IF  DR  =  1  THEN  GPA(I); 
END  KSIMPLE; 


Comments 

DA  and  DR  are  global  vari- 
ables. J  values  1-17 
indicate  the  result  is 
stored  in  Rl .  17-34  indicate 
result  stored  in  R2. 
DA,  DR  are  changed  in  the 
GPA  if  operations 
properly  executed. 


Register  Assignments  (Values  for  I) 

1  —  Rl  =  BUS 

2  —  R2  =  BUS 


Arithmetic  Operations  (Values  for  J) 


0  - 
1/18 
2/19 
3/20 
4/21 
5/22 
6/23 
7/24 
8/25 


BUS 
BUS 
BUS 
BUS 
BUS 
BUS 
BUS 
BUS 
BUS 


0 
Rl 
R2 
-Rl 
-R2 
-Rl 
Rl  -1 
Rl+1 
R2+1 


9/26 
10/27 
11/28 
12/29 
13/30 
14/31 
15/32 
16/33 
17/34 


BUS 
BUS 
BUS 
BUS 
BUS 
BUS 
BUS 
BUS 
BUS 


Rl  +  R2 

Rl  -  R2 

Rl  a   R2 

Rl  v   R2 

Rl  ©  R2 

Rl  =>  R2 

Rl  *  2 

Rl  /  2 
MEM(L) 
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Listing  of  GPA 

PROCEDURE  GPA(INTEGER  VALUE  RESULT  I); 
BEGIN 

IF  I>0  THEN 
BEGIN 

IF  DR=1  THEN 
BEGIN 

CASE  I  OF  BEGIN 
R1:=BUS; 
R2:=BUS; 
END; 
DR:=0; 
DA:=1; 
END 
ELSE 

BEGIN  INTEGER  SW;  BITS  TEMP; 
CASE  I  OF  BEGIN 
BUS:=R1; 
BUS:=R2 

BUS:  =  (R1  AND  #10000)  OR  (-R1  AND  #FFFF) ; 
BUS:=(R2  AND  #10000)  OR  (-R2  AND  #FFFF) ; 
BEGIN 

ADDER(#0,R1,#1,TEMP); 
BUS:=TEMP; 
END; 
BEGIN 

ADDER(R1,#2,#1,TEMP); 
BUS:=TEMP; 
END; 
BEGIN 

ADDER(R1,#2,#0,TEMP); 
BUS:=TEMP; 
END; 
BEGIN 

ADDER(R2,#2,#0,TEMP); 
BUS:=TEMP; 
END; 
BEGIN 

ADDER(R1,R2,#0,TEMP); 
BUS:=TEMP; 
END; 
BEGIN 

ADDER(R1,R2,#1,TEMP); 
BUS:=TEMP; 
END; 

BUS:=R1   AND  R2; 
BUS:=R1   OR  R2; 
BUS:  =  (R1   AND-R2  AND  #1FFFF)   OR  (-R1   AND  R2  AND  #1FFFF); 
BEGIN 

I:=0; 
END; 
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BEGIN 

TEMP:  =  (R1  SHR  16)  AND  #1; 

BUS:=(TEMP  SHL  16)  OR  (Rl  SHL  1); 
END; 
BEGIN 

TEMP:  =  (R1  SHR  16)  AND  #1; 

BUS:=(R1  SHR  1)  OR  (TEMP  SHL  16); 
END; 

BUS:=MEM(L); 
END: 


DA:=0: 
DR:=1 
END; 
END 
ELSE  BEGIN 

R1:=#0; 
DR:=0; 
DA:=1; 
END; 
END  GPA; 
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APPENDIX  C 


DIAGRAM  OF  FULL  ADDER 


X+Y+C 


u  XC  +  YC  +  XY 

CARRY 


SUM 


[(XC  +  YC  +  XY)'  +  XYC]  (X  +  Y  +  C)= 


X'Y'C  +  X'YC  +  XY'C  +  XYC 
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APPENDIX  D 
RTM  DIAGRAM  OF  16  BIT  MULTIPLER 


Control  Part. 


I 


entry 


Ks(C  *■  16) 


EI 


Kd(P  <0>) 


b  P<Q- 


jt-n. 


Ks(P  «•  P/2) 


/ 


Ks(P+-(P+MPD) 
/2) 


Ks(C  «-  C-l) 


Kd(C  =  0) 


Data  Part: 


-16 


DM(constant) 


P^ 


^(p+mpc|)/2 
^- 


DM(gpa;P, 
MPD) 


O 


X^ 


^u 


DM(gpa;C)        = 


evfn 
complete 


Bus  =  o 


K(bus) 


0         11 

exit 
At  entry  Multipler    :=  P<15:0>;     P<31:16>:  =  0;  or 


[ 


MULTIPLIER 


31  16  15  0 

Multiplicand:   =  MPD<31:16>;  MPD<15:0>:   =0;  or 


MPD | Q 


31 


16  15 


C:=    [ 


0 


.     15  0 

RESULT:  =  P<31 :0>  at  exit 
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APPENDIX  E 
FLOATING  POINT  ADDITION 


ENTER/  (bits  value  result  A,  bit  value  B) 


CONCATENATE  RES- 
ULTANT MANTISSA 
WITH  LARGEST 
EXPONENT. 


T 


ADD  1  TO  EXPONENT 
OF  SMALLEST 


I 


SHIFT  MANTISSA  OF 
SMALLEST  RIGHT  1 


RETURN 
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RT 

APPENDIX  F 
RTM  DIAGRAM  FOR  ARCSIN 

DIAGRAM  (Control   Part  Only) 
Control   Part 

Kdiv(X^X/BINRY(10)) 

0) 

t 

Kmul(SQ<-X*X) 

Kmul(NUM*NUM*TOTAL) 

t 

t 

Kdiv(SQ<-SQ/BINRY(100)) 

Kdiv(NUM<-NUM/BINRY(100)) 

t 

t 

Ks(SUM<-BINRY(100)) 

Ks(NL2«-NUM  -2) 

t 

t 

Kdiv(SUM«-SUM/BINRY(81)) 

Kmul(NL2«-NL2  *  NL2) 

t 

Ks(Rl«-SQ) 

Kd  i  v  ( SUivk-5  UM/  NL2 ) 

t 

t 

Kdiv(R)«-Rl/BINRY(121)) 

Ks( TOTALS UM  +  SUM) 

t 

t 

Ks(TOTAL«-Rl   +  SUM) 

Kd(NUM  <   3) 

1 

t 

t° 

Ks(NUM<-BINRY(9)) 

Ks(NUM^UM-2) 

t 

t 

Kmul(NUM<-NUM*SQ) 

f 

Kmul(TOTAU-TOTAL*X) 

t 

t 

* 

Kdiv(NUM^NUM/(NUM-l)) 

Kdiv(T0TAL«-T0TAL/BINRY(100)) 

T 


RETURN  TOTAL 


Connections  to  BUS,  GPA,  Memory,  etc.  is  similar  to  that  shown  in 
Appendix  D. 
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LISTING  OF  PROCEDURE  ARCSIN 


BITS  PROCEDURE  ARCSIN(BITS  VALUE  X); 

BEGIN  BITS  SQ,SUM,TOTAL,NUM,NUMLSl 
NUMLS2,  TNUM; 

ADDER  (X,#A,#0,X); 

KDIVIDE(X,BINRY(10)); 

SQ:=X; 

KTIMES(SQ,X); 

ADDER(SQ,#64,#0,SQ); 

KDIVIDE(SQ,BINRY(100)); 

SUM:=BINRY(100); 

KDIVIDE(SUM,BINRY(81 )); 

R1:=SQ; 

KDIVIDE(R1,BINRY(121)) 

ADDER(SUM,Rl,#0,TOTAL); 

NUM:=BINRY(9) 
LOOP:TNUM:=NUM; 

ADDER(NUM,#2,#1,NUMLS1), 

KTIMES(NUM,SQ); 

KDIVIDE(NUM,NUMLS1); 

KTIMES(NUM, TOTAL); 

ADDER(NUM,#64,#0,NUM); 

KDIVIDE(NUM,BINRY(100)); 

SUM:=BINRY(100); 

ADDER(NUMLSi ,#2,#1 ,NUMLS2); 

KTIMES(NUMLS2,NUMLS2); 

KDIVIDE(SUM,NUMLS2); 

ADDER(NUM, SUM, #0, TOTAL); 

ADDER(TNUM,#4,#1,NUM); 

IF  NUM=#1  THEN  GO  TO  FINI ; 

GO  TO  LOOP; 
FINI:KTIMES(TOTAL,X); 

ADDER(TOTAL, #14, #0, TOTAL); 

KDIVIDE(T0TAL,BINRY(10)); 

TOTAL 
END  ARCSIN; 


37 


The  Algorithm 


APPENDIX  G 
TRIANGULATION  ALGORITHM 


target 


tail 


R2,B2,T2 
N     /> 


defensive  platform 


R2,B2,T2 


intercept  bearing 

i 


<-theta 


defensive  weapon 
speed 


ts-j  ^defensive  platform 


FIRST  STAGE 


SECOND  STAGE 


First  Stage  -   Compute  relative  course  and  speed  of  target  using 
two  inputs  of  range  and  bearing  of  target,  time 
between  inputs  and  trigonometry  functions  SINE, 
ARCSIN  and  ARCTAN. 

Second  Stage  -  Compute  Intercept  Bearing  using  relative  course  and 
speed  of  target,  relative  speed  of  intercept  weapon 
and  Law  of  Sines. 
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The  Flowchart 


RECEIVE  TWO 
SUCCESSIVE  INPUTS 


I 


COMPUTE  ANGLE  TAU 
BETWEEN  INPUTS 


I 


COMPUTE  COURSE  AND  SPEED 

OF  TARGET  USING  RIGHT 

TRIANGLES  CONCEPT 


I 


USING  LAW  OF  SINES 
COMPUTE  ANGLE  BETWEEN 
RELATIVE  MOVEMENT  LIME  (B2) 
AND  INTERCEPT  BEARING 


>    STAGE  1 


COMPUTE  ANGLE  CHI  BETWEEN 
TARGET  COURSE  LINE  AND 
INTERCEPT  LINE 


I 


ADD  180°,  ANGLE  TAU 
AND  ANGLE  CHI 


STAGE  2 


I 


ADD  (OR  SUBTRACT  ACCORDING  TO 

DIRECTION  OF  TARGET  MOVEMENT) 

THE  ABOVE  TOTAL  TO  R1 


I 


ADJUST  ABOVE  TO  BEARING 

BETWEEN  0  AND  359  AND 

RETURN  AS  INTERCEPT  BEARING 


J 
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